For one-to-many (i.e., point-to-multipoint) services over systems such as IP multicast, IP datacasting (IPDC) and multimedia broadcast/multicast services (MBMS), file delivery (or discrete media delivery or file download) is an important service. Many of the features for delivering files over point-to-point protocols such as file transfer protocol (FTP) and hypertext transfer protocol (HTTP) are problematic for one-to-many scenarios. In particular, the reliable delivery of files—that is the guaranteed delivery of files—using similar one-to-one (i.e., point-to-point) acknowledgement (ACK) protocols such as transmission control protocol TCP is not feasible.
The Reliable Multicast Transport (RMT) Working Group of the Internet Engineering Task Force (IETF) is in the process of standardizing two categories of error-resilient multicast transport protocols. In the first category, reliability is implemented through the use of (proactive) forward error correction (FEC), that is, by sending a certain amount of redundant data that can help a receiver in reconstructing erroneous data. In the second category, receiver feedback is used in order to implement reliable multicast transport. Asynchronous Layered Coding (ALC, RFC 3450) is a protocol instantiation belonging to the first category, while the NACK-Oriented Reliable Multicast (NORM) protocol presents an example of the second category. The details of ALC and NORM protocols are discussed in more detail in publications entitled “Asynchronous Layered Coding (ALC) Protocol Instantiation” (RFC 3450) and “NACK-oriented Reliable Multicast Protocol” (Internet Draft) prepared by the Working Group of the IETF. The contents of these publications are fully incorporated herein by reference.
Access networks on which these protocols can be used include, but are not limited to, wireless multiple-access networks such as radio access networks of the Universal Mobile Telecommunications Services (UMTS) system, wireless local area networks (WLAN), Digital Video Broadcasting-Terrestrial (DVB-T) networks and Digital Video Broadcasting-Satellite (DVB-S) networks.
Briefly, ALC protocol is a proactive FEC based scheme that allows receivers to reconstruct mangled packets or packets that have not been received. ALC protocol uses FEC encoding on multiple channels, allowing the sender to send data at multiple rates (channels) to possibly heterogeneous receivers. Additionally, ALC protocol uses a congestion control mechanism to maintain different rates on different channels.
ALC protocol is massively scalable in terms of the number of users because no uplink signalling is required. Therefore, any amount of additional receivers does not exactly put increased demand on the system. However, ALC protocol is not 100% reliable because reception is not guaranteed, thus it is generally not described as robust.
NORM, in turn, specifies the use of negative acknowledgement (NACK) messages in order to signal which packets of data (or otherwise defined “data blocks”) expected to arrive at the receiver were not received at the receiver (or were received incorrectly). In other words, receivers employ NACK messages to indicate loss or damage of transmitted packets to the sender. Accordingly, a receiver that “missed” some data blocks from a data transmission can send a NACK message to the sender requesting the sender to re-transmit the missed data block or blocks. NORM protocol also optionally allows for the use of packet-level FEC encoding for proactive robust transmissions.
File Delivery over Unidirectional Transport (FLUTE) is a one-to-many transport protocol that builds on FEC and ALC building blocks. It is intended for file delivery from sender(s) to receiver(s) over unidirectional systems. It has specializations which make it suitable to wireless point-to-multipoint (multicast) systems. The details of FLUTE protocol are discussed in more detail in the publication entitled “FLUTE—File Delivery over Unidirectional Transport” (Internet Draft) prepared by the above-mentioned Working Group of the IETF. The contents of this publication are fully incorporated herein by reference.
NACK messages are not generally NORM specific, but they can also be used in connection with other protocols or systems. When using NACK messages in connection with FLUTE sessions (or in other sessions using a transport layer protocol especially directed to support one-to-many transmission) the identification of the missing packets (or blocks) is an important issue. The usage of protocols intended for one-to-one (or point-to-point) transmission, such as TCP, and their acknowledgement methods are not necessarily feasible here. For example, the use of TCP acknowledgement methods in a one-to-many system would produce a considerable amount of overhead. Accordingly, there is a need for reliably identifying the packets not received in a one-to-many scenario so that accurate re-transmission can be performed.